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(57) Abstract: The Dynamic Registration and Configuration Protocol (DRCP) provides a framework for registering and passing 
configuration information to roaming mobile hosts (105). DRCP is compatible with DHCP and can switch to using DHCP protocol 
if only DHCP servers (165) are present in the network (1 75). Most importantly, DRCP allows rapid configuration by moving address 
consistency checking from the critical path. Other novel features of DRCP allow: a) clients to know when to get a new address 
independent of the layer-2 access technology, b) efficient use of scarce wireless bandwidth, c) clients to be routers, d) dynamic 
addition or deletion of address pools to any DRCP node, and e) message exchange without broadcast. 
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METHOD AND SYSTEM FOR DYNAMIC REGISTRATION 
AND CONFIGURATION PROTOCOL 

RELATED UNITED STATES APPLICATIONS/CLAIM OF PRIORITY 

5 This patent application is a non-provisional counterpart to, and claims the 

benefit of priority of provisional application serial number 60/161,220, which was filed 
on October 22, 1999. 

TECHNICAL FIELD OF THE IINVENTION 

• 10 The present invention relates generally to networks and more specifically to a 

method, system, apparatus and product for providing dynamic registration and 
configuration of mobile clients in end to end wireless/wireline Internet Protocol (IP) 
networks. 

15 BACKGROUND 

Various TCP/IP registration and configuration network protocols exist today. 
Popular protocols include: Mobile IP (MIP) and Dynamic Host Configuration Protocol 
(DHCP). Although its primary function is providing location services and continuous 
connectivity to roaming users, Mobile IP also provides for flexible registration and 

20 configuration capabilities. The Mobile IP client sends registration information to a 
Foreign Agent on the Layer 2 network to which the client is connected. The Foreign 
Agent can then configure the client, after getting authorization from the user's Home 
Agent. While Mobile IP is a solution to manage device mobility throughout the global 
Internet, its costs can be too high for many applications, and it is not compatible with 

25 the widely deployed DHCP. 
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For example, Mobile IP provides networks transparency above the IP layer. 
This transparency is achieved at a relatively high cost (e.g., triangular routing) 
compared to simply getting a new care-of-address. In many cases, however, this 
transparency is not needed, e.g., for web browsing. 

5 

The Dynamic Host Configuration Protocol (DHCP) provides a well-tested and 
widely-deployed framework for passing configuration information to network hosts. 
By means of dynamic allocation of IP addresses, DHCP allows for leasing of network 
addresses, recovery of network addresses upon expiration of those leases, as well as 
10 subsequent re-use or reallocation of network addresses. DHCP, however, was designed 
for hosts on a fixed LAN, not for mobile hosts roaming among commercial wireless 
networks. 

Rapid configuration (milliseconds rather than seconds) is necessary for most 
15 roaming users. DHCP specification says a client should, and most implementations do, 
the widely known Address Re-use Protocol (ARP) check after it receives an assigned 
address before the assigned address is used by the client. This checking by the client 
typically results in a long delay before communication can resume. 



20 Other limitations of DHCP are that it: (a) has no facilities for detecting a move 

to a new subnet, (b) involves a large message size (parts of which are not needed), (c) 

requires a DHCP node to be a server or a relay agent, and not both, and (d) identifies 

machines (e.g., by MAC address) rather than users (e.g., by a network access identifier 

of the form such as user@domainl The fixed functionality limits architectural choices 

25 that might be attractive to wireless service providers, where a subnet router may act as a 
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relay agent when a node first moves into the domain, but as a server for previously 
authorized nodes. 

Given the foregoing, there is a need for a solution which can address the 
5 problems of the prior art and provide for rapid client registration and configuration of a 
roaming mobile host. The registration functionality would enable roaming mobile hosts 
to rapidly and automatically register their presence and their requirements with 
networks. The configuration functionality would enable networks to automatically 
configure roaming mobile hosts to the particular network characteristics. Moreover, 
10 there is a need for a solution which provides efficient use of scarce wireless bandwidth, 
allows mobile hosts to be routers, allows flexible proxies that can act as both relay or 
server and allows dynamic server and relay reconfiguration. 

SUMMARY 

15 The present invention, hereinafter referred to as the Dynamic Registration and 

Configuration Protocol (DRCP) is a protocol directed to solving the forgoing needs. In 
a basic application, DRCP, although providing some new configuration capability, has 
no other function except registration and configuration. In more advanced applications, 
DRCP provides additional functionality, including providing information about the 

20 location of a network registration, service negotiation, or mobility agent. 

DRCP is built directly on UDP and DP and is a lightweight dynamic 

configuration protocol. DRCP provides the critical functions necessary for roaming 

users. For example, DRCP allows rapid configuration by moving address 

25 consistency checking from the critical path. Other features and/or advantages allow: 
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a) clients to know when to get a new address independent of the layer-2 access 
technology, b) efficient use of scarce wireless bandwidth, c) clients to be routers, d) 
dynamic addition or deletion of address pools to any DRCP node, and e) message 
exchange without broadcast. 

5 

Therefore, in accordance with one aspect of the present invention, there is 
provided, a system, method, apparatus and product for rapidly and dynamically 
registering and configuring a mobile client in a second network environment; said 
mobile client having traveled from a first network environment to said second network 

10 environment, said method comprising: 

providing a plurality of valid IP addresses associated with said second network 
environment for assignment to mobile clients; said valid EP addresses having been 
positively checked for availability; broadcasting a request for at least one of said 
plurality of valid EP addresses; 

15 monitoring said first network environment to sense movement of said mobile client 
from said first Network environment to said second network environment to provide a 
request for a valid IP address; and providing at least one of said plurality of valid IP 
addresses associated with said second network environment to be assigned to said 
mobile client. 

20 

In accordance with a second aspect of the present invention, there is provided a 
data structure representing a signaling message having a small footprint to provide 
efficient use of scarce wireless bandwidth, 

25 These and other aspects, features and advantages of the present invention will 
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become better understood with regard to the following description, appended claims, 
and accompanying drawings. 

BRIEF DESCRIPTION OF THE DRA WINGfS) 
5 Turning now to the drawings: 

Figure 1 is a high level functional architecture of an IP-based network having 
mobile nodes in communication with various wired or wireless access networks. 

10 Figure 2 is an embodiment of a DRCP client-server model in accordance with 

the teachings of the present invention. 

Figure 3 is one embodiment of a DRCP client message format in a accordance 
with the teachings of the present invention. 

15 

Figure 4 is one embodiment of a DRCP server message format in a accordance 
with the teachings of the present invention. 

Figure 5 is one embodiment of an OPCODE field of a DRCP message in 
20 accordance with the teachings of the present invention. 

Figure 6 is one embodiment of an OPTION field of a DRCP message in 
accordance with the teachings of the present invention. 

25 Figure 7 illustrates a preferred DRCP signaling and message flow sequence 
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when a DRCP client moves into a new administrative domain and/or subnet. 

Figure 8 illustrates a preferred DRCP signaling and message flow sequence 
when a DRCP extending a lease within an administrative domain. 

5 

Figure 9 illustrates a preferred DRCP signaling and message flow sequence 
when a DRCP client re-negotiating an OFFER message sent by a DRCP server. 

10 DETAILED DESCRIPTION OF THE PRESENT INVENTION 

Referring more specifically to the drawings, for illustrative purposes the present 
invention is embodied in the system configuration, method of operation and product or 
computer-readable medium such as floppy disks, conventional hard disks, CD-ROMS, 
Flash ROMS, nonvolatile ROM, RAM and any other equivalent computer memory 
15 device, generally shown in Figures 1 - 9. It will be appreciated that the system, method 
of operation and product may vary as to the details of its configuration and operation 
without departing from the basic concepts as disclosed herein. 



ARCHITECTURE 

20 

Figure 1 is a high level network architecture diagram of an IP based network 

that is suitable for implementing DRCP. As shown,, the network comprises a plurality 

of components in communication with each other; the components comprising: at least 

one mobile client 105, access networks 115-130, edge routers and controllers 160, 165, 

25 regional backbones 170, 180, domain agents 185, 195, an inter domain agent 190 and 
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the global Internet 175. Each of the forgoing components are well-known in the art and 
accordingly will not be discussed. Figure 1 is meant to be very general functional 
diagram. It does not, for example, specify where a base station is located. A base 
station could be located within the access networks, thus being a Layer 2 base station or 
5 located within the edge router, thus being an IP base station. Moreover, the Domain 
and Inter-Domain agents, which perform functions such as registration and AAA, are 
shown as separate single boxes; however each could be implemented as multiple nodes 
(possibly in a hierarchical structure). 

10 DRCP is based on a client-server model. Figure 2 shows how the DRCP client 

and DRCP server may map onto the architecture shown in Figure 1. The DRCP client- 
server model is similar to the DHCP client-server in most respects. There are, 
however, some differences. 

15 First, unlike DHCP, any DRCP node (including the client) can be on a router 

or host. Second, unlike DHCP, all DRCP nodes run the same program. The only 
thing that makes a DRCP node a server is that it has configuration information, 
including an address pool and other configuration parameters to be used on an 
interface. A DRCP server must configure its own interface using the configuration 

20 information for that subnet. This allows for more flexible and robust operation. 



DRCP MESSAGE FORMATS 

DRCP messages have the same basic semantics as those used in DHCP. 
For example, a DHCPOFFER message has the same basic functions (and 
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name) as a DRCP_OFFER message. New DRCP messages are needed, however, in 
order to minimize message size thereby providing use of scarce wireless bandwidth. 
Like DHCP, DRCP uses UDP as its transport protocol. All DRCP messages are sent 
in UDP/IP packets to special DRCP ports and, are preferably, 32-bit aligned. There 
5 are two types of DRCP signaling messages running on three different DRCP ports: 

a) All messages from a DRCP client are sent to the DRCP_SERVER_PORT port. 



b) All messages from a DRCP server are sent to the DRCP_CLIENT_PORT port, 
10 except the DRCP_ADVERTISMENT. 

c) DRCP_ADVERTISMENT messages from a DRCP server are sent to the 
DRCP_ADVERTISEMENT_PORT port on the DRCP client. 

15 What follows is a list and description of typical DRCP client messages sent by a DRCP 
client. 



DRCPJDISCOVER: Registration message sent by a DRCP-client on its local subnet 
to request a new address and other configuration parameters. While a 
20 DHCPDISCOVER message must be broadcast [DHC], a DRCPJDISCOVER 
message may be broadcast orunicast depending whether the client knows the 
address of a DRCP Server (e.g., from a DRCP_ ADVERTISEMENT]. 

DRCP_REQUEST: Registration message sent by a DRCP-client on its local subnet to 
25 request extending the lease on an address. 
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DRCP JNFORM: Registration message sent by a DRCP-client on its local subnet to 
request new configuration parameters. This could be used, for example, if the client 
already has an externally configured network address. 

5 

DRCP_DECLINE: Registration message sent by a DRCP-client on its local subnet to 
request a different address, either because the one assigned is not 
acceptable (e.g., it is already in use by another client) or because the client has 
moved to a new subnet. 

10 

DRCPJRELEASE: De-registration message sent by a DRCP-client on its local subnet 
to relinquish a network address and cancel remaining lease. 

DRCP_ ACCEPT: Registration message sent by a DRCP-client on its local subnet in 
15 response to an OFFER from servers. The client accepts of fered parameters from 
one server and implicitly declining offers from all others. 

What follows is a list and description of typical DRCP server messages sent by a DRCP 
server. 

20 

DRCPJDFFER: Configuration message sent back to client on the same subnet where 
the DRCP server node received a DRCP_DISCOVER message. 

DRCP^ACK: Configuration message broadcast by a Server on its local subnet in 
25 response to a DRCP_ACCEPT. 

9 
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DRCP_NAK: Message sent to a client or clients (may be broadcast) to tell them 
not to use an address or other service they requested, (e.g., when a client is using a 
wrong address). 

5 

DRCP_ ADVERTISEMENT: Server periodically broadcasts (or unicast in response to 
a client using an incorrect address) the network information (such as Server IP address 
or Network address). Listening to this, client can 
understand the subnet change. 

10 

All DRCP messages from the DRCP client (to the DRCP_SERVER_PORT) 
have the same general format (size shown in braces) as shown in Figure 3: The various 
fields are: 



15 



20 



FTFTD 
op 

htype 

hlen 

xid 

chaddr 
802.X) 
options 



OCTETS 

1 

1 

1 

1 

var. 
var. 



DESCRIPTION 
Message OpCode. 
Hardware address type. 
Hardware address length in bytes. 
Transaction ID. 

Client hardware address (e.g 16 bytes for 
Optional parameters field. 
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All DRCP server messages from the DRCP server (to the 
DRCP_CUENT_PORT) have the same general format (except a 
DRCP.ADVERTISEMENT) as shown in Figure 4. The fields are the same as those of 
the DRCP client message format except that it includes an additional field: ciaddr. 

5 

FIELD OCTETS DESCRIPTION 

ciaddr 4 Client IP address 

10 What follows is a description of the content of the various field shown in Figures 3 and 
4: 

The opcode field consists of version number (ver), message type (mtype) and 
broadcast(B) flag as shown in Figure 5. 

15 

Possible values for Message types include: 

Message Value Message Type 

20 0 0 0 1 DRCP_DISCOVER 

0 0 10 DRCP.REQUEST 

0 011 DRCPJNFORM 

0100 DRCP.ACCEPT 

0 10 1 DRCP_DECLINE 

25 0 1 1 1 DRCP.RELEASE 

11 
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1001 



DRCP.OFFER 



1010 



DRCP_ACK 



1011 



DRCP_NAK 



1111 



DRCP.ADVERTISEMENT 



10 



15 



20 



Htype: see ARP section in "Assigned Numbers" RFC. For example: Htype = '1 9 
means it is a lOmb ethernet. 

Hlen: Length of chaddr field in bytes. For example Hlen is set to '6' for lOmbps 
ethernet. 

Xid: A random number chosen by the client. It is used by the client and server to 
associate messages and responses between a client and a server. 

Ciaddr: The IP address assigned to a client by a server. 

Options: All information, other than what is in the common header, must be included 
as options. All options have a common 4 byte header as shown in Figure 6. 

METHOD OF OPERATION 

A node is initially assumed to only know its interfaces which are running the 
DRCP-client and its security associations. If there are multiple interfaces, each 
interface may be configured in a different way. For example, one interface may be 
configured by DRCP, another using a locally stored address, and a third as a DHCP- 
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client. After boot-up, however, any interface configured as a DRCP interface listens to 
messages on a specified port designated a DRCP_ADVERTISMENT_PORT. During 
any message exchange a transaction id 

is used between the client and server and they must match for a given exchange. 

5 

If a DRCP interface does not have a local address pool it becomes a DRCP 
client. The client first broadcasts a DRCP_DISCOVER message (similar to a 
DHCPDISCOVER message) to a designated port on the DRCP server, i.e. 
DRCP_SERVER_PORT. It then listens for a response. If it gets no response after a 
10 predetermined time-out period, i.e., DRCP_RETX_TIMEOUT, it resends the 
DISCOVER message. This process repeats for up to a predetermined number of 
retransmissions, i.e. DRCP_RETX_MAX. 



If an unconfigured DRCP client receives a DRCP_ADVERTISEMENT 
15 message (on the DRCP_ADVERTISEMENT_PORT), then it will change to a unicast 
state, so the next DRCP_DISCOVER message will be unicast to the source address 
of the DRCP_ADVERTISEMENT message. 

If the DRCP client receives an OFFER message, it can immediately configure 
20 its interface with that address. There is no requirement to do ARP checking (as in 
DHCP). After getting an address the DRCP client may periodically send out 
DRCP_REQUEST messages to renew the lease. These message are retransmitted 
until acknowledged by a DHCP_ACK message. 
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If a configured DRCP client receives a DRCP_ ADVERTISEMENT message 
(on the DRCP_ADVERTISEMENT_PORT), then it will check if it can still use the 
same IP address. If it cannot use the same IP address, then the client must unicast a 
new DRCP_DISCOVER message in order to get a new address. This helps to detect 
5 the subnet change. It happens only when a client moves to a new subnet. 

If a DRCP interface has a local configuration information (including an address 
pool) for that interface, then it becomes a DRCP server. The DRCP server must first 
use the first address from the address pool to configure its own interface. It can then 
10 use the rest of the address pool to allocate individual addresses directly to DRCP 
clients on the same subnet as that interface. 

The DRCP server may send periodic DRCP_ADVERTISEMENT messages 
(on the DRCP_ADVERTISMENT_PORT) every DRCP_ADVERTISMENT_PERIOD 
15 time. 

The server listens for a DHCPJDISCOVER broadcast or unicast message on 
its designated port, i.e., DRCP.SERVER _PORT. If it gets a DHCP J3ISCOVER 
message, then the DRCP server can immediately send a DRCPJDFFER message 
20 with valid IP address and other configuration parameters from its configuration 
information. The DRCPJDFFER message will be resent for a predetermined time 
period, every DRCPJDFFER .PERIOD for up to DRCP_SERVER_MAX 
retransmissions, or until it receives a DRCP_ACCEPT or DRCP JDECUNE message 
from a DRCP client. 

25 
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Figure 7 depicts the signaling and message flow when a DRCP client moves 
into a new administrative domain and/or subnet. At 701, the DRCP server initiates 
periodic ADVERTISEMENT messages. Upon receiving the ADVERTISEMENT 
message, at 702, the DRCP client transmits and retransmits the DISCOVER message 
5 until it gets an OFFER message or the timer expires. At 703, the DRCP server 

transmits and retransmits the OFFER message until it gets an ACCEPT or DECLINE 
message, at 704, or the timer expires. Notably, a key difference between DRCP and 
DHCP is that there is no ACK message from the DRCP server to the DRCP client. 
Also, a DRCP client accepts with an ACCEPT rather than a REQUEST message. A 
10 second key difference is that configuration can be used as soon as the OFFER message 
is received by the DRCP client (duplicate detection is handled in the background). 

Figure 8 depicts the signaling and message flow when a DRCP client renews or 
releases an existing lease. If a DRCP client wants to renew or release its lease, then 
15 there will be a flow of DRCP messages as follows: At 801, a DRCP client sends a 

message requesting a renewal or a release of an existing lease. At 802, a DRCP server 
sends an ACK message in response to the REQUEST/RELEASE message. 

Figure 9 depicts the signaling and message flow when a DRCP client 
20 renegotiates its OFFER message. At 901, a DRCP client sends an OFFER message to a 
DRCP client. At 902, the DRCP client sends a DECLINE message to the DRCP server. 
At 903, upon receiving the DECLINE message the DRCP server can either do 
nothing or it can send a new OFFER message to the DRCP client. At 903, in 
response to the new OFFER message, the DRCP client can either decline the OFFER 
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message again and send another DECLINE message or it can accept the OFFER 
message and send an ACCEPT message to the DRCP server. 

Having now described a preferred embodiment of the invention, it should be 
5 apparent to those skilled in the art that the foregoing is illustrative only and not 

limiting, having been presented by way of example only. All the features disclosed in 
this specification (including any accompanying claims, abstract, and drawings) may be 
replaced by alternative features serving the same purpose, and equivalents or similar 
purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of 
10 the modifications thereof are contemplated as falling within the scope of the present 
invention as defined by the appended claims and equivalents thereto. 
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CLAIMS 

What is claimed is: 

5 1. A method for rapidly and dynamically registering and configuring a mobile client in 
a second network environment; said mobile client having traveled from a first network 
environment to said second network environment, said method comprising: 
providing a plurality of valid IP addresses associated with said second network 
environment for assignment to mobile clients; said valid IP addresses having been 

10 positively checked for availability; 

broadcasting a request for at least one of said plurality of valid IP addresses; 
monitoring said first network environment to sense movement of said mobile client 
from said first Network environment to said second network environment to provide a 
request for a valid IP address; and 

15 providing at least one of said plurality of valid IP addresses associated with said 
second network environment to be assigned to said mobile client. 

2. A computer-readable medium having computer-executable instructions for 

performing a method for rapidly and dynamically registering and configuring a mobile 

20 client in a second network environment; said mobile client having traveled from a first 

network environment to said second network environment, comprising: 

providing a plurality of valid IP addresses associated with said second network 

environment for assignment to mobile clients; said valid DP addresses having been 

positively checked for availability; 

25 broadcasting a request for at least one of said plurality of valid IP addresses; 
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10 



15 



20 



monitoring said first network environment to sense movement of said mobile client 
from said first Network environment to said second network environment to provide a 
request for a valid IP address; and 

providing at least one of said plurality of valid IP addresses associated with said 
second network environment to be assigned to said mobile client. 

3. A system for rapidly and dynamically registering and configuring a mobile client in 
a second network environment; said mobile client having traveled from a first network 
environment to said second network environment, comprising: 

at least one processor programmed to: 

provide a plurality of valid IP addresses associated with said second network 
environment for assignment to mobile clients; said valid IP addresses having 
been positively checked for availability; 

broadcast a request for at least one of said plurality of valid IP addresses; 
monitor said first network environment to sense movement of said mobile client 
from said first Network environment to said second network environment to 
provide a request for a valid IP address; and 

provide at least one of said plurality of valid IP addresses associated with said 
second network environment to be assigned to said mobile client. 

4. A computer-readable medium having stored thereon a data structure representing a 
signaling message having a small footprint to be sent from a mobile client to a server, 
said data structure comprising: 

a first field containing data representing a message opcode; 

a second field containing data representing a hardware address type; 
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a third field containing data representing a hardware address length; 

a fourth field containing data representing a transaction ID; 

a fifth field containing data representing a hardware address of said mobile client. 

5 5. A data structure as in claim 4 further comprising a sixth field containing data 
representing one or more optional parameters. 

6. A data structure as in claim 4 wherein said data representing said message opcode 
includes data representing a version number, a message type and a broadcast flag. 

10 

7. A data structure as in claim 6 wherein said message type is chosen from the group 
consisting of a DISCOVER, REQUEST, INFORM, ACCEPT, DECLINE, RELEA SE, 
OFFER, ACK, NAK ADVERTISEMENT message type. 

15 8. A computer-readable medium having stored thereon a data structure representing a 

signaling message having a small footprint to be sent by a server to a mobile mobile 

client, said data structure comprising: 

a first field containing data representing a message opcode; 

a second field containing data representing a hardware address type; 
20 a third field containing data representing a hardware address length; 

a fourth field containing data representing a transaction ID; 

a fifth field containing data representing a hardware address of said mobile client; and 
a sixth field containing data representing an BP address of said mobile client. 

25 
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9. A data structure as in claim 8 further comprising a seventh field containing data 
representing one or more optional parameters; 

10. A data structure as in claim 8 wherein said data representing said message opcode 
5 includes data representing a version number, a message type and a broadcast flag. 

1 1. A data structure as in claim 10 wherein said message type is chosen from the group 
consisting of a DISCOVER, REQUEST, INFORM, ACCEPT, DECLINE, RELEASE, 
OFFER, ACK, NAK ADVERTISEMENT message type. 

10 

12. In an IP based network, a method for rapidly and dynamically registering and 
configuring a mobile client in a second network environment; said mobile client having 
traveled from a first network environment to said second network environment, said 
method comprising: 

15 providing at least one server in communication with said IP based network, said server 
having a pool of IP addresses and configuration parameters; 
said server: 

performing ARP checking on said IP address pool to provide a pool of valid IP 
addresses; 

20 listening for a request for an IP address from a mobile client; 

offering a valid IP address; and 

sending said valid IP address and said configuration parameters to said mobile 
client thereby eliminating the need for said mobile client to itself perform ARP 
checking of said valid IP address. 

25 
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13. A method as in claim 12 further comprising said server repeatedly offering said 
valid IP address until either a predetermined time period has expired, a predetermined 
number of offer transmissions has expired or a mobile client has responded to said offer 
of an IP address. 

5 

14. In an IP based network, an apparatus for rapidly and dynamically registering and 
configuring a mobile client in a second network environment; said mobile client having 
traveled from a first network environment to said second network environment; said 
apparatus comprising: 

10 at least one server having an interface for communicating within said IP based network, 
said server having configuration parameters and a pool of IP addresses; 
said server programmed to: 

perform ARP checking on said IP address pool to provide a pool of valid IP 

addresses; 

15 listen for a request for an IP address from a mobile client; 

offer a valid IP address; and 

send said valid IP address and said configuration parameters to said mobile 
client thereby eliminating the need for said mobile client to itself perform ARP 
checking of said valid IP address. 

20 

15. An apparatus as in claim 14 wherein said server is further programmed to 
repeatedly offer said valid IP address until either a predetermined time period has 
expired, a predetermined number of offer transmissions has expired or a mobile client 
has responded to said offer of an IP address. 

25 
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16. In an IP based network, a method for rapidly and dynamically registering and 
configuring a mobile client in a second network environment; said mobile client having 
traveled from a first network environment to said second network environment, said 
method comprising: 

5 providing at least one mobile client in communication with said IP based network; 
said mobile client: 

requesting an IP address from a server having a plurality of IP addresses and 
configuration parameters associated; and 

receiving a valid IP address and said configuration parameters from said server; 
10 said server having already performed an ARP check of said valid IP address 

thereby eliminating the need for said mobile client to itself perform an ARP 
check of said valid DP address. 

17. A method as in claim 16 further comprising said mobile client repeatedly 

15 requesting an IP address from said server until either a predetermined time period has 
expired, a predetermined number of request transmissions has expired or a server has 
responded to said requests for an IP address. 



18. In an IP based network, an apparatus for rapidly and dynamically registering and 
20 configuring a mobile client in a second network environment; said mobile client having 
traveled from a first network environment to said second network environment, said 
apparatus comprising: 

at least one mobile client having an interface for communicating within said IP based 

network; said mobile unit programmed to: 

25 request an IP address from a server having a plurality of IP addresses and 

22 



WO 01/31822 




PCT/USOO/29055 



configuration parameters associated therewith; and 

receive a valid IP address and said configuration parameters from said server, 
said server having already performed an ARP check of said valid IP address 
thereby eliminating the need for said mobile client to itself perform an ARP 
5 check of said valid IP address. 



19. An apparatus as in claim 18 wherein said mobile client is further programmed to 
repeatedly request an IP address from said server until either a predetermined time 
period has expired, a predetermined number of request transmissions has expired or a 
10 server has responded to said requests for an IP address. 
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